Fix the release workflow's cache scope and branch selection - #37
Merged
Conversation
Manual-only `Release Docker image` workflow: pick a branch (or tag/SHA) and it builds the runtime image and pushes it to Docker Hub as one multi-arch manifest per tag (linux/amd64 + linux/arm64 by default), so a single tag serves x86_64 and Apple Silicon alike. Each run publishes `<branch>-<short-sha>` (immutable) and `<branch>` (moving); an extra tag and `:latest` are opt-in inputs, as is the platform list. Needs `DOCKERHUB_USERNAME` / `DOCKERHUB_TOKEN` secrets, checked up front so a missing one fails in seconds rather than after the build. The Dockerfile's `debugpy-payload` and `builder` stages are pinned to `$BUILDPLATFORM`: both produce architecture-independent output (a tarred pure-Python wheel, and tsc's `dist/`), so they run natively once instead of once per target under QEMU. The final stage keeps its own `pnpm install --prod`, so native bindings still come from the target architecture. README documents both the CI workflow and the local `docker buildx` push. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
CI is the way images get published; the manual `docker buildx` recipe was a second, drift-prone copy of what the workflow already does. With only one subsection left, its heading is folded into "Publishing the image". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
`type=gha,scope=release-${{ inputs.platforms }}` expanded to
`type=gha,scope=release-linux/amd64,linux/arm64`. A `type=gha` value is
itself a comma-separated key=value list, so the comma inside the platform
list terminated `scope` and buildx read the leftover `linux/arm64` as a bare
key: `ERROR: invalid value linux/arm64`, before any build step ran.
One shared `release` scope instead. The per-platform-set keying it replaces
was not worth having anyway - GHA cache scopes are separate namespaces, so
sharing one lets a single-platform run reuse layers a multi-arch run already
cached rather than starting cold.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
`release.yml` landed on master via #36 with the same content this branch already had, so the whole file conflicted add/add. Resolved by keeping this branch's cache scope: master's `scope=release-${{ inputs.platforms }}` is the form that fails with `ERROR: invalid value linux/arm64` on a multi-platform run, since a `type=gha` value is itself a comma-separated key=value list. Dockerfile and README were already byte-identical. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
The `branch` input defaulted to `master`, so picking a branch in "Use workflow from" and leaving the input alone ran that branch's workflow file against master's tree and tagged the image `master-<sha>`. Two branch selectors where one silently overrode the other. The input is now optional and empty by default, falling back to `github.ref_name` - the branch the run was dispatched from. Filling it in is reserved for the case it was meant for: running a newer version of this workflow against an older ref. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
The workflow now always builds the branch it was dispatched from. Checkout takes no `ref:` at all, so it uses the dispatch commit by default, and the tag slug comes from `github.ref_name`. One branch picker instead of two, and no way for the built ref to disagree with the branch chosen in "Use workflow from". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes to the release workflow #36 added. No new functionality —
Dockerfileand the multi-arch build itself are untouched.The multi-platform cache scope was invalid
expanded to
type=gha,scope=release-linux/amd64,linux/arm64. Atype=ghavalue is itself a comma-separated key=value list, so the comma inside the platform list terminatedscopeand buildx read the leftoverlinux/arm64as a bare key:That killed the run before any build step, so any dispatch with the default multi-platform list failed. Only a single-platform run (no comma) got through.
Both cache flags now use one shared
releasescope. The per-platform-set keying it replaces wasn't worth having: GHA cache scopes are separate namespaces, so sharing one lets a single-platform run reuse layers a multi-arch run already cached instead of starting cold.The
branchinput silently overrode the branch you pickedThere were two branch selectors, and the one you didn't touch won. Use workflow from chose which
release.ymlran; thebranchinput chose what got checked out and tagged — and it defaulted tomaster. Dispatching from a feature branch and leaving the input alone therefore ran that branch's workflow against master's tree and pushedmaster-<sha>,master,latest.The input is gone.
actions/checkoutnow takes noref:at all, so it uses the dispatch commit, and the tag slug comes fromgithub.ref_name. One branch picker, and no way for the built ref to disagree with it.Remaining inputs:
image,extra_tag,latest,platforms.README
Updated to match: Use workflow from is the only branch to choose, and the
/-to--tag slugification is now stated.🤖 Generated with Claude Code
https://claude.ai/code/session_01TzoV12kHAHm6EFNmUfZedq